I'm having a hard time understanding the difference between message_private_key and stacks_private_key from just these comments. Can you help me understand why there need to be two private keys?

stacks_private_key controls money, message_private_key just lets you sign FROST messages. Users might have very different protection strategies for each.

One of my tasks for Nakomoto is to review how we store private keys, and offer various strategies for keeping them safe. Ideally we want to allow users to keep their stacks_private_keys in an HSM; all private keys should at least be trivially encrypted locally.

Having separate private keys from the start means we don't have to change this later.

I can update the comment on the stacks_private_key as well to indicate what it is used for if that helps (communicating with the stacks node/stacker db contract)?

Thanks for updating the comment @jferrant!

@xoloki I agree in principle that the keys ought to be separate and have different storage strategies, but I'm curious why the signer needs to have a key that controls large amounts of STX in the first place? When the user stacks their STX in pox-4, they'd additionally set a dedicated signing key for the purposes of signing blocks, chunks, and transactions (i.e. the counterpart to message_private_key). The STX would presumably be managed by the user's wallet, not the signer. Additionally, the PoX rewards would be sent to a (separate) address of the user's choosing, which almost certainly would not be under the control of the signer. Please help me understand what I'm missing?

Totally possible that I'm making bad assumptions here. I though the way PoX worked was that users stacked significant (~100k) STX for each reward slot, and that the STX address associated with the stacking wallets would be the same STX address that Signers will use to talk to sbtc contracts etc.

If this is a bad assumption, and the STX address the Signer will use with stackerDB is not the address which controls the large STX stake, then yeah we can just use the STX private key for wsts message signing ECDSA too.

The users don't stack to specific reward slots per se; they just stack a large quantity of STX, and depending on how much STX they stacked relative to everyone else, they are allotted zero or more reward slots by the system at the start of the next reward cycle.

That said, the key that holds the STX and performs the stacking operation would not need to be known to the signer. Instead, the act of stacking from this high-value key would assign a different block-signing key for the signer to use. Depending on what you think about this, it may even be desirable to have the user delegate two keys to the signer: one for signing Stacks blocks, and one for signing Bitcoin sBTC transactions. But in no case would the signer ever possess the key that controls the user's STX.

Would it make sense to use a draining iterator for the following? This state won't be used again in this signing round, right? It would save you some clone()s and ensure this signature generation step only happens at most once.

Linking the comment I had on the other PR here for visibility: #3923 (comment)